NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/dcom/modems-part1/2258

Internet Message Format | 1996-08-05 | 3.5 KB

Path: news.computek.net!news
From: [e-mail] (Wayne Fulton)
Newsgroups: comp.dcom.modems
Subject: Re: Astounding high CPS rate!
Date: 21 Jan 1996 19:28:54 GMT
Organization: none
Message-ID: <4du45m$[e-mail]>
References: <4db4ra$[e-mail]> <[e-mail]> <4djh7h$[e-mail]> <[e-mail]>
NNTP-Posting-Host: dal1590.computek.net
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
X-Newsreader: WinVN 0.99.7

In article <[e-mail]>, [e-mail]
says...
>Some time ago I read somewhere that there was supposed to be a "guard
>time" of two bit times between the stop bit of one character and the
>start bit of the next. This would suggest that one would have to
>divide by 12 (8+1+1+2). However, real-world performance doesn't
>suggest anything like this. Anyone ever hear of this "guard time"?


Guard time is the name for the patented Hayes one second safety delay
required both before and after the +++ escape sequence to switch the
modem from online to command mode, so we can send ATH0 for example.
This is all programmable in S registers, but it has nothing to do with
data rates.

There is no delay necessary between a stop bit and the next start bit.
The stop and start bits themselves validate the character sync, that
is their purpose.

Stop bits used to be two bit times way back in the WWII TTY days, but
anything we've used in over 20 years uses a 1.0 bit stop bit length,
same length as all the other bits.

Even so, 10 bit data (with start and stop bits) is only used in the
asynchronous modem cable between serial port and modem port, and 10
bits is also sent by plain-jane modems without error control (the old
or cheap ones).   But modern V.42 modems discard start and stop bits,
pack all data bytes into 128 or 256 byte blocks, number the blocks for
reference, and append computed CRC bytes.  They have no use for
start/stop bits nowdays, the V.42 modem to modem link is synchronous,
not asycnchronous.   Start/stop bits still exist because that is the
way our serial ports are designed.

So the theretical maximum possible data rate of a 14400 bps V.42 modem
is 14400/8=1800 CPS, but which must include the added V.42 overhead
bytes.  That is the definition of a 14400 bps modem, more is not
possible.   However V.42 is 20% faster than non-error control modems
because it sends 20% fewer bits per byte (8 vs 10).    We usually use
a protocol like Zmodem or tcp/ip that adds additional similar overhead
bytes, so when counting the original file data, we typically see
between 1620 and 1670 CPS on 14400 Zmodem from a fast host, mostly
depending on if the two modems negotiate 128 or 256 byte blocks.

The serial port still sends 10  bit characters, so even if we were
offered a 14400 baudrate, the port could go only 14400/10=1440 CPS
throughput, and so could not keep up with the 1800 CPS 14400 bps
modem.  So therefore, we set the port baudrate to 19200 baud (or
more), so the port can keep up with the modem.

V.42bis compresses the data (if the data is compressible) and
depending on the compressibility of the specific data, we might see 2
or 3 times faster throughput at the serial port if we set the port
fast enough.  Typically we set the port 4 times faster than the
carrier so we are ready for anything.  However, the 14400 bps modem
still goes only 14400 bps, in that compression only changes the data
(fewer bytes).   The throughput definitely is faster, but only because
the data is smaller.

--
Wayne
[e-mail]